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Procede et systfeme pour le transfert informations 
d' administration de r^seau de communication, 

Le domaine de 1* invention est celui de 
1' administration de .r6seaux de communication. Le terme 
administration est a prendre ici dans son sens le . plus 
large c'est a dire qu'il concerne tant la configuration 
que la gestion, voire la commande des equipements de 
reseaux de communication. 

Pour configurer un equipements on peut par exemple 
utiliser un protocole d' interface interactive tel que le 
protocole connu TELNET. Ce protocole est normalise mais 
les donn^es acce^sibles ne le sont pas. Ce qui pose 
probleme, en particulier pour une quantite considerable 
d* equipements de reseaux comme c'est souvent le casrj 

La gestion cqmprend entre autres, la prediction^ et la 
detection de f antes • Dans l'6tat connu de la techniqi^e, on 
peut citer a titre. d' exemple le document WO02/4 69i8 qui 
divulgue un systeme qui traite des informations obtenues 
de capteurs associes ^ des variables repertori^es dans une 
base d' information d' administration nommee MIB (Management- 
Information Base) . Pour en permettre une interpretation et 
un traitement a grande echelle relativement a de nombreux 
equipements, les definitions des variables soht sp§cifi^tes 
au moy^n d'un langage normalise nomme SMI (Structure of 
Management. Information) . Un protocole nomme SNMP (Simple 
Network Management Protocol) , • lui aussi normalise, permet 
d'acceder aux variables par echange de requetes/reponses 
entre equipements dur^seau. 

Comme c'est le cas par exemple dans le document 
WO02/17094, les variables peuvent concerner des 
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a.spositifs ,ui sent tant des capteurs de te™p*-ture des 
.taL d^axarme ou des ad.esses r4seau de type IP que des 
; events p.us co^p.e.es. Po« de te.s 

»,o« d'oMet. repertories dans une ou plusxeurs 
::;;;ren;e; mxb. ce aoou«e„t divux^ue des doyens pour 
i„ter.acer Xes dispos,t«s sous S.MP , 

La technique basee sur le tripj- 

^ T^nt les specifications des 

atteint une certaine maturite. Tant les sp 

attemr u . . ^ r-^l les des objets qui y sont 

MIB elles-m§iaes ainsi que celles des j ^ 

. . ^ la fois en termes de 

— "^^/rtair^r^XaJrlt.:: des .XB est .Xen 

TIZT: venlxLent au «oye„ d.— Xs„es teXs ^e 
maXtrisee, e document US600943X. 

«ux proposes par exer»pXe dans Xe 
I.. identification absoXue des objets par 

et X209), identification absoXue des instances d ob.ets 
et X2U3), i fournissent un 

par i' index d> instance, font que Xes MlB 

^ -A n«r Xes opArateurs. !•« 

^*.fArentleX normatif prise par xes p 
retereniie „.iHs4 pour de nombreux 

crotocoie SNMP est Xargement utiXise pou 

, . et de services teXs en tSmoignent Xes 

types d'equipements et de servi „„„,/„322 
, documents «O0X/44924, EPXX58720 ou encore '^"^^''J^^^ 

Cependant, le protocoXe S««P n'est pas -J^"*"-"^ 
pour un transport de voXume important de donn.es car xX 
a olte une surcharge en informations suppXAment aires 
::::ead, consid.rabXe. .e mode -r requ.tes r n 
S ,poXXin„ rend difficiXe une optimisation qestio 
interne des donne^s J.auo i-s -ri i 
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n^achines, augmente consid^rablement la bands passante 
necessaire, en premiere approxiraation d'un facteur triple, 
au detriment de la bande passante utile pour les donn6es 
des utilisateurs. Bien que, approximativement 85%. des 
5 Ob jets des MIB soient des champs de tables, bien que, 
approximativement 99, 9% des;' instances soient des instances 
de ces objets, c'est a dire de champs de tables, le 
protocole SNMP n' optimise pas la consultation des tables. 
Mors que les .champs d^une lighe de table • ont le m^me 
10 index, le protocole SNMP repete 1 ■ index pour chaque champ, 
ajoutant ainsi un sur-debit d' environ cent octets par 
ligne de table consult6e. 

un objet de 1' invention est un precede pour minimiser 
une bande passante necessaire aux transf erts . 
15 d' informations d' administration de reseau de^ . 
communication, lesdites informations concernant des objets. 
relatifs k des elements mat^riels, logiciels ou de; 
fonctionnement de ^eseau, repertories dans une base, 
d- information d' administration et a chacun desquels est 
20 associee une specification en langage formel. 

Le procede est remarquable en ce .qu'il comprend des. 
etapes consistant a: 

- gSn^rer 4 partir de ladlte spiolf ioatlon pour chaque 
objet, un couple de mot= dont la valeur du premier mot est 
25 relative i une indication de 1' objet et la valeur du 
deuxitaie mot est relative 4 une. longueur d ■ information de 

1 ' ob j et ; 

- construire un patron comprenant un ensemble ordonne de 
- - - couples de mots generis et un identif icateur dudit patron, 
30 permettant d'^mettre ensuite une ^suite ordonnee 
d' informations correspondant audit patron. 
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Plus particuliferement, le proc6d6 comprend des Stapes 
consistant a: 

- parcourir un arbre de la base d' information 
d' administration dont chaque noeud est associ6 A un objet; 

5 - tester ^ chaque nceud si 1' objet est de type scalaire ou 
table; 

- construire le patron en ajoutant le couple de mots 
g6ner§ au patron si 1' objet est de type scalaire; 

- construire un autre patron dit de table si 1' objet est 
10 de type table pour les objets de la table. 

Avantageusement, le precede comprend des etapes 
consistant k construire en plus un patron de configuration 
comprenant les couples de mots gen^res pour des objets a 

acces modifiable. 
15 Un objet de 1' invention est aussi un systeme pour 

minimiser une bande passante nScessaire aux transferts 
d' informations d' administration de r^seau de 
communication, lesdites informations concernant des objets 
relatifs a des Elements mat^riels, logiciels ou de 

20 fonctionnement de reseau, repertories dans une base 
d' information d' administration et a chacun desquels est 
associee une specification en langage formel. 

Le systeme est remarquable en ce qu'il comprend un 
module traducteur agence pour generer a partir de ladite 

25 specification pour chaque objet, un couple de mots dont la 
vaieuK du premier mot est relative k nr.^^ i ndic3.i:i...i-i 
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Plus particulierement, le module traducteur est 
agenc6 pour parcourir un arbre de la base d' information 
H..dministration dont chaque nceud est associe ^ un ob^et, 

5 pour tester ^ chaque n.ud si I'objet est de type scalaire 
ou table et pou. construire ' le patron en ajoutant le 
couple de mots g.n^r6 au patron si I'objet est de type 
scalaire ou construire un autre patron dit de table sx 
■l-objet est de type table pour les objets de la table. 

10 • Avantageusement, le module traducteur est agenc6 pour 
construire en plus un patron de configuration comprenant 
les couples de mots gen^res pour des objets ^ acces 

modifiable. ^ i ' 

par exemple, , . ie systime , comprend un module 
15 superviseur agenc* pour oollecter des mesures et un module, 
d-exportation agenc* pour transmettre i un, serveur, au, , 
moins un ticlcet de do«.6es relatives 4 ces mesures en Ift 
faisant pr^c^der du patron de ce ticket de donntes. 

I,. invention sera mieux comprise a partlr de I'exenple 

-4.^ r^r-&.If>nt en ref^reuce aux dessins 
20 de mise en ceuvre d^crit a present en reo-e 

annexes dans lesquels: 

la figure 1 est un schema de syst^me .conforme ^ 

1' invention; . 

- les, figures 2 4 1 montrent des etapes de precede 

25 conforme a 1 'invent ion; 

-. la figure 8 represents une , structure d" arbre pour un 
objet particulier de type table; 

- la figure 9 montre un patron de 1' objet represent^ en 

figure 8; ^ 
30 - la figure 10 montre un exemple de ticket de donnees, 

conforme au patron de la figure 9; 
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- la figure 11 repr6sente une structure d'arbre pour un 
autre objet particulier de type table; 

- la figure 12 raontre un patron de 1' objet represente en 

-P -i r^yt Vi:i 1 1 r 
X. JU »-* -t- w f 

5 - la figure 13 montre un exemple de ticket de donn6es, 
conforme au patron de la figure 12; 

- la figure 14 est un schema d' application industrielle 
possible; 

- la figure 15 montre un patron de table genere par le 
10 systeme de la figure 14; 

- la figure 16 montre un exemple de ticket de donn^es, 
conforme au patron de la figure 15; 

- la figure 17 montre un autre patron de table g6nere par 
le systeme de la figure 14; 

- les figures 18a k 18c montrent un exemple de ticket de 
donn^es, conforme au patron de la figure 17. 

Dans le systeme d^crit k present en r^f^rence k la 1, 
un traducteur 10 coraprend des moyens de communication avec 
un reseau 16 en vue de recevoir des commandes et de 
transmettre des donn^es . Le traducteur 10 est une machine 
telle que par exemple un ordinateur comprenant un 
processeur et des programmes necessaires pour mettre en 
oeuvre les etapes de precede decrites ulterieurement en 
r4f6rence aux figures 2 a 6. Le traducteur 10 comprend des 
moyens de lecture dans des bases de donnees 11 et 15, des 
rn.-.-.-enn rr'Vcritur= dans une memoirs do masoi 11. ■•'•-•s moyens 
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information Base ou PIB pour Process Information Base en 

anglais) . 

■ La base de donn^es 15 contient des regies de 
^..dnntion pour fournir chacune un type de champ de patron 
I. au moins un objet specific dans la base de donn^es 11. 

La inemoire .14 est agencee pour contenir des patrons 
generis par le traducteur 10 . . 

La m^moire 12 est agencee pour contenir des arbres 
relatifs ^ des objets de MIB ou de PIB. 

■ Le module 13 est agence pour effectuer un 
typage/nommage d'objets communiques par le traducteur 10. , 
Le module 13 dispose d'un processeur et de prograr^es 
necessaires . mettre en »uvre les etapes de precede 
d6crites ulterieurement en r^f^rence a la figure 7. 

En reference i la figure 2, . une premiere etape 1, 
consiste ^ activer dans le traductetar . 10, une generation, 
de patrons (templates) pour un arbre en y associant un, 
parametre nomm6 "ObjetRoot". L'arbre peut pointer sur un, 
ensemble de MIBs ou. de PIBs, sur une" MIB, un sous arbre- 
d'une MIB ou une table d'une MIB'. L' activation peut ^tre 
faite ^ la demande ou dans le cadre de 1 - initialisation du . 
systeme a partir du reseau 16. L'activation fournit une 
base de numerotation. des patrons qui est un parametre 
nomme "base_template_ID" . On comprendra naturellement que 
25 les noma donnas entre guillemets dans la description sont 
simplemenf.choisis ^ titre de memorisation mn^motechnique 
sans signification particuliere et sans valeur limitative, 
c-est ^ dire que tout autre nom peut etre choisi sans 
sortir du cadre de I 'invention, les noms choisis pour la 
30 description d^signant bien entendu toujours les memes 
donn^es comme c'est le cas pour les " references aux 
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dessins. L' activation fournit aussi un parametre relatif ^ 
une generation de patrons de configuration, et nomrn^ ici 
"Generation_templates_configuration". Lorsque la valeur de 
ce parametre est positionn6e par exemple a 0, cela 
signifie que le proc6de doit gen^rer uniquertient des 
patrons standards, c'est a dire essentiellement orientes 
vers la surveillance et la signalisation (monitoring) - 
Lorsque la valeur de ce parametre est positionnee par 
exemple a 1, cela signifie que le procede doit generer en 
plus des patrons de configuration, c'est a dire 
essentiellement orientes vers la configuration des 
6quipements. Un patron standard est relatif A tous les 
Ob jets et index de I'arbre considere alors qu'un patron de 
configuration est relatif aux index, a des objets 
accessibles en ecriture et k la creation d'objet. 

Une seconde 6tape 2 consiste k lire les 
specifications des MIB ou PIB demand6es, dans la ra^moire 
11. Cette memoirs peut etre n' imports quel type de memoirs 
(memoire vive, disque ou reseau) . Cette 6tape est 
optionnelle. Elle n'est pas necessaire si les 
specifications sont d6j^ disponibles dans le traducteur 
10. Cette etape peut etre renouvelee en cours de 
traitement si necessaire. 

One troisi^me etape 3 consiste a construire un arbre 
25 de nommage des objets k partir des valeurs des 
identificat^urs ..I'-bjets ccntenus -rlans l-s MIB ou FTE. 
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ob:et de £a,on 4 ranger ohague oMet dans I'arbre de 
nonage en utilisant les OID des oblets. On rappelle qu'un 
identificateur d'objet (OID) est un type partloulxer du 
langage flSN.l[X2081 utilisant un arbre unique dSfxnx pour 
5 .associer un identifiant portable » une donn^e. Cet 
identifiant est absolu et ■ transferable. La fonctxon de 
transfert couran«r.ent utilisee- est dMinie dans [X209] . Par 
exe-ople SKMP utilise les r.gles d'encodage de K209. X209 
est souvent nomm* BER (Basic Encoding Rules) , 
0 ■ Dans une quatritoe itape 4, le traducteur 10 cr*e des 
patrons en executant les .tapes d.crites . present en 
reference aux figures 3a et 3b. 

une *tape 39 consiste I, lire la demande de g.n.ratxon 
de patrons activ*e dans I'^tape 1 pour les ob^ets presents.. 
,5 de rarbre de I'objet -ObjetRoot" et 4 lire le parametre , 
de base de num^rotation des patrons "base_template_ID" . . , 
une *tape 40 consiste 4 cr^er. une ou plusieurs 
constantes ,ul peoaettent de distlnguer des families de 
patrons (template, en fonction qu'un .patron se rapporte ^ 
20 une MIB. une PXB, ou » une autre famille de langage de 
specification. Dans l^exen^le de la. figure 3a, une. 
■ . - MTB est nominee 

constante re±ai:iv^^ ^ ^ 
"DefinitionDeTemplateDeMIB" 4 laquelle est affectee une 
valeur deux co™»une 4 tous les patrons de MIB. D'autres 
25 Constances' peuvent .tre attributes avec d'autres valeurs 
slgnifiant que la, structure construite dans les etapes 
suivantes, est un patron de PIB ou autre. 

one 4tape 41 consiste 4 cr.er un patron 
"DefTicket.ObjetRoof. pour cet arbre. Le patron est une 
30 liste initialement vide de couples par expmple de mots de 
seize bits. 
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Une etape 42 consiste 



k creer une variable 
et ^ lui 



" nume r o DuChampCour ant _De f T i c ke t_Ob j e t Roo t " 

affecter une valeur nulla, ^ cr6er une variable 
"current_teinplate_ID" et a lui affecter la valeur du 
paramStrl "base_template_ID" , ^ creer une variable 
••ObjetRoot_template_ID et a lui affecter la valeur de. 
"current_teniplate_ID", et enfin a incrementer la valeur de 
la variable "current_template_ID" . La premiere variable 
sert a num^roter les champs de donnees qui seront ajout^s 
progressivement dans les 6tapes suivantes pour construire 
un patron. La deuxifeme variable sert k num^roter les 
differents patrons qui seront cr66s dans les Stapes 
suivantes de sorte que le patron de I'arbre lui-in§me soit 
nuraerote avec la troisieme variable dont la valeur est 
celle du param^tre de base fourni en 6tape 1. La deuxidme 
variable est enfin incr6ment6e de fapon h §tre disponible 
avec une nouvelle valeur pour un autre patron genere dans 
les stapes suivantes a partir des objets de I'arbre. 

A la suite des etapes 41 et 42 de creation de patron 
standard, une etape 35 consiste a tester si le parametre 
"Gen6ration_templates_configuration" vaut 1. Une r^ponse 
positive au test declenche des 6tapes 36 et 37 pour creer 
un patron de configuration parallelement au patron 
standard. Comme nous le verrons par la suite, un patron de 
25 configuration ne concerne que des objets modifiables parmi 
pntron standard. La nicindir t.?ill- cui en Le-uii.^.- 
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patron de configuration quant a lui, a pour usage de fixer 
des valeurs de variables, voire de cr^er de nouvelles 
.esures dans le syste:,e de mesure, son sens de circulation 
est g^n^ralement du lieu de gestion vers le Ixeu de 

L'etape 36: de meme nature que I'etape 41, consxste k 
creer un patron de configuration noinme 

"DefTicket_configuration_ObjetRoot"- 

L'^tape 37, de meme nature que l'etape 42, consiste ^ 
„„e variable nomm6e 

10 creer- . ' , ^ t ■ 

"DefTicket_configuration_ObjetRoot_Template_ID" et a lux 

affecter la valeur de "current_template_ID" ainsi qu'a 
^^^er une . variable nommee 

"nombreDeChamps_Configuration_ObjetRoot" et a lui affecter- 
15 une valeur nulle." La premiere variable de conf igurati;,n,, 
sert ^ num^roter le patron de. configuration directement,,^ 
la suite du patron standard. . La deuxi^xne variable ^e.. 
configuration sert ^ compter le nombre de champs du patron 
de configuration qui est inf^rieur ou €gal au nombre .de 
20 champs du patron standard. • _ 

A la suite des Stapes 36 et 37, une etape 38 consxste 
incrementer la variable "current_template_ID" pour 
identifier une eventuelle creation suivante de patron. 
L'6tape 38 est . egalement activee en cas" de r^ponse 
25 n^gativb au test de l'etape 35 de sorte que la variable 
"current_template_ID", est incrementee independamment du 
fait qu.'un patron de configuration soit ou ne soit pas 
cr66. Ainsi, chaque patron standard aura un identif icateur 
de m.me nature, par exemple pair et le patron de 
30 configuration correspondant aura un identif icateur de 
num^ro suivant, de nature alors impair e qui permet a la 
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foi de distinguer la nature des patron et d'en faire la 

correspondance . 

Un patron standard initialement vide et 
respect ivement si coiranande par I'etape 1, un patron de 
configuration initialement vide, ayant et6 cr6es par les 
6tapes 41 et 42, respectivement par les etapes 36 et 37, 
le proc^di se poursuit apres l'6tape 38, par une procedure 
de parcours de I'arbre, dicrit k present en reference k la 
figure 3b. 

Une succession d' Stapes 43 ^ 47 consiste a balayer 
I'arbre contenu dans la m^moire 12 en coinmengant par la 
racine "ObjetRoot". 

L'^tape 43 consiste a initialiser un objet courant k 

I'objet racine. 

L'^tape 44 consiste k tester si I'objet est un objet 
de type scalaire. Une MIB contient deux categories 
d' Ob jets, les objets individuels encore appel6s scalaires 
et les tables regroupant des objets en lignes, chaque 
ligne etant identifies par un index. Une r^ponse positive 
au test de I'etape 44 declenche une procedure scalaire. 
une r^ponse negative au test de I'etape 44 declenche une 
etape 45. 

L'etape 45 consiste a tester si I'objet est de type 
table. Une r^ponse positive au test de I'etape 45 
declenche une procedure table. Une reponse negative au 
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extraire des regies de traduction de table ou 
respectivement .d'objet scalaire, a partir de la base de 
regies 15. 

Aores execution de la procedure table ou" de la 
5 procedure scalaire selon le cas, une etape 46 teste si 
1' Ob jet courant est le dernier objet de I'arbre. Une 
r^ponse positive au test dfe I'etape 46 declenche une 
procedure de cloture d^crite ulterieurement en r^f^rence a 
la figure 6. One reponse negative au test de l'6tape 4 6 
10 declenche une 6tape 47. L'etape 47 prend I'objet suivant 
de I'arbre comae objet courant et reboucle 1' execution du 

proced6 sur 1' etape 44. 

Apr^s execution de la procedure de cloture, une etape.. 
6 transfere les patrons g6n6r6s par le proced^ pour- 
15 r6pondre ^ une requite en provenance du r^seau 16,, 
directement d'un autre 6quipeiaent ou en interne.. 

En reference ^ la figure 4a, la procedure table^.. 
coxnmence par une 6tape 30 dans laquelle est. cr.ee une, 
variable nommee ."DefTicket_Table_template_ID" et a 

nn ;,ff^ctee la valeur courant e . de 

20 laquelle est attectzee j-c* 

"current_template_ID". ' Cette variable sert 

d'identificateur d'un patron standard de la table d6tect6e 
en etape 44, 

Dans une 6tape 31, la valeur de "current_template_ID" 
25 est incr^mentee, de fagon a etre disponible pour une 
6ventuelle- cr§ati,on suivante de patron. 

une 6tape 51 consists alors a creer un patron de la 
table, nomme DefTiclcet_Table^Ti. De la m^me fagon que le 
patron de I'arbre cri^ en 6tape 41, le patron de la table 
30 cre6 en 6tape 51, est une liste initialemerpt vide. 
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A la suite des stapes 30, 31 et 51 de creation de 
patron standard, une 6tape 19 consiste a tester si le 
parametre "Generation_templates_conf iguration" vaut 1. One 
reponse positive au test declenche des etapes 20 k 22 pour 
cr6er un patron de configuration parall^lement au patron 
standard. Comme nous le verrons par la suite, un patron de 
configuration ne concerne que des objets modifiables parmi 
ceux du patron standard. La moindre taille qui en result e, 
r6duit les flux d' information necessaires lors d'une 
configuration de fagon k en accelerer le deroulement . 

L'6tape 20 de meme nature que I'^tape 51, consiste a 
cr6er un patron de configuration noinin^ 
" Def Ticket_conf iguration_Table_Ti " . 

L'6tape 21, de m^me nature que I'etape 30, consiste k 
15 cr6er une variable noram^e 

"DefTicket_configuration_Table_Ti_Teniplate_ID" et a lui 
aff ecter la valeur de "current_template_ID" . 

L'etape 22 consiste k cr^er une variable noitmiee 
"nombreDeChamps_Configuration_Table_Ti" et k lui affecter 

20 une valeur nulle. 

La variable creee et positionnee en etape 21, sert k 
numeroter le patron de configuration directement k la 
suite du patron standard. La variable creee et positionnee 
en etape 22, sert a compter le nombre de champs du patron 
de configuration qui est inferieur ou egal au nombre de 
chamos -.'u patron standard. 
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"current_template_ID" est incr^ment^e independamment du 
fait qu'un patron de configuration soit ou ne soit pas 
cr66. Ainsi, chaque patron standard aura un identif icateur 
de meme nature, par exemple pair et le patron de 
5 configuration correspondant aura un identif icateur de 
nurafero suivant, de nature alors impaire qui permet a la 
foi de distinguer la nature : des patron et d'en faire la 

correspondance - 

Une 6tape 52 consiste a cireer une variable locale 
10 nomm^e "num6roDuChampCourant_DefTicket_Table_TI" et a lui 
affecter une valeur nulle. L'etape 52 est executee 
indifferemment k la suite de I'etape 51 ou, de I'etape 23, 
le num6ro de champ courant servant ^ la fois a indicer les ^ 
Champs de donn^es. du .patron- de table standard et a ^n .. 

15 compter la quantite. . 

• . un patron standard initialement vide et si comman46 
par I'etape 1, respectivement un patron de configuration 
initialement vide, ayanf6t6 crees par les Stapes 30, 51 
et 52, respectivement par les stapes 20 a' 22, le proced6 
SB poursuit par une procedure de' parcours de la table, 
decrit k present en reference a la figure 4b. 

Dans une 6tape 54, le traducteur 10 lit la definition 
SMI de la ligne d' entree de la table et la clause INDEX de 

la definition. 

une boucle d'etapes 55 a 57 consiste ensuite a lire 
sequentieliement la definition SMI de chaque objet de 
I'index. Dans 1' etape.. 55,. le ;traducteur 10 lit un objet de 
1' index en commengant par le premier objet suite a 
1' execution de I'etape 54. Le traducteur 10 d^clenche 
alors la procedure scalaire pour 1' objet lu en etape 55 
apres avoir d6clenche en pr^ambule I'etape 9 pour extraire 
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les regies de traduction si elles existent, de cet objet k 
partir de la base de regies 15. L'^tape 9 est en fait 
optionnelle . 

L'etape 56 consists a tester si 1' objet courant est 
le dernier objet de 1' index. Una r^ponse negative au test 
reboucle le processus en etape 57 pour 1' objet suivant de 
1- index de fa?on a r6iterer l'etape 55. Une reponse 
positive au test de l'etape 56 indique que tous les objet s 
de 1' index ont 6t§ trait^s. 

Apr^s la dernifere execution de l'6tape 56, une boucle 
d'fetapes 58 a 61 consiste k traiter les objets de la table 
qui ne font pas partie de 1' index. 

En 6tape 58, le traducteur 10 lit un objet de ligne 
en coiranen?ant par le premier objet de la definition de la 
ligne de table apres la derni^re execution de l"6tape 56. 

Dans l'etape 59, le traducteur 10 teste si 1' objet 
courant est un objet de I'index. Une riponse negative au 
test declenche apres execution de l'etape 9 pour 1' objet 
courant, la procedure scalaire a la suite de laquelle 
l'etape 60 est activ^e. Une reponse negative au test de 
l'6tape 59 declenche directement l'etape 60. 

Dans l'etape 60, le traducteur 10 teste si 1' objet 
courant est le dernier objet de la table. Une reponse 
negative au test de l'etape 60 declenche l'etape 61 dans 
laquelle le traducteur 10 reactive l'etape 58 pour 1' objet 
suirant ."le la table. Une repcise positive hu test -i- 
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d'appel de la procedure scalaire. Ainsi, lorsque la 
procedure scalaire est d^clenchee a partir de I'etape 44, 
la variable " numeroDuChampCour anf ' correspond & la 

"num6roDuChampCourant_DefTicket_0bjetR6ot". 

5 Llrsque la procedure scalaire est declench^e a partir de 

l-etape 55 ou de I'etape 59, la variable 

"num^roDuChampCourant" correspond a la variable 

"num6roDuChaxnpCourant_DefTicket_Table_Ti" . L' etape 48 

n«,,v* la ^ variable 

incremente la valeur de 

10 "numeroDuChampCourant" . 

Dans I'^tape 49, le traducteur 10 lit la definition 
SMI de I'objet de fagon ^ en extraire son type, son sous- 
type, sa taille minimale, sa taille xnaximale et son mode, 
d-acc^s. Le mode d'acc^s permet de distinguer si I'ob^et • 
15 courant est modifiable ou non. 

Dans une etape 7, le traducteur 10 transmet au moduli- 
de typage norronage 13, le type I'objet, le sous-type d^. 
I'objet, la taille minimale de I'objet, la taille maximal^ 
de I'objet, le numero du champ courant et la r%gle de 
20 traduction de I'objet courant. 

Dans une etape 8, le module de typage 13 transmet au 
traducteur 10 les valeurs d'un couple (type', longueur) 
relatif ^ I'objet courant. 

Dans une 6tape 50, le traducteur 10 ajoute le couple 
25 {type, , longueur) dans le patron nomme localement 
DefTicket_X qui, ■ est soit , DefTicket_ObjetRoot sx la 
procedure scalaire a 6t6 d^clench^e ^ partir de l'6tape 
44 soit le patron DefTicket_Table_Ti si la procedure 
scllaire a M d6cl^nchee a partir de I'^tape 55 ou de 
30 I'etape 59. 
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Apres execution de I'etape 50, le traducteur 10 
active une etape de test 32 qui consiste a verifier si un 
patron de configuration est cree, c'est h dire si 
"G6n6ration_templates_conf iguration", en abrege Gtc, vaut 
5 1 et ^ verifier si I'objet courant est modifiable. 

Une reponse positive au test de I'etape 32, declenche 
une 6tape 33 dans laquelle une variable nominee localement 
"NombreDeChamps_Configuration" est incr§ment6e. La 
variable "NorabreDeChamps_Conf iguration" correspond soit a 
10 la variable "NombreDeChamps_Conf iguration_ObjetRoot" si la 
procedure scalaire a et6 d6clench6e k partir de I'etape 
44, soit ^ la variable 

"NombreDeChamps_Configuration_Table_Ti" si la procedure 
scalaire a 6t6 d^clenchee ^ partir de I'etape 55 ou de 

15 I'etape 59. 

Dans une 6tape 34, le traducteur 10 ajoute le couple 
(type, longueur) dans le patron noiran§ localement 
DefTicket_Configuration_X qui est soit 

DefTicket_Configuration_ObjetRoot si la procedure scalaire 

20 a ete declenchee a partir de I'etape 44, soit le patron 
DefTicket_Configuration_Table_Ti si la procedure scalaire 
a et6 d§clench6e a partir de l'6tape 55 ou de I'etape 59. 
On observe que le couple (type, longueur) est ajout6 dans 
le patron de configuration, avec le m§me repere que dans 

25 le patron standard, a savoir le numero de champ courant. 
.^insi. rhoquo .;hamp reiatif au type et a la lon-rueur d'un 
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Apres execution de I'^tape 34 ou suite A une r6ponse 
negative au test de l'6tape 32, la procedure scalaire se 
termine par un retour pour poursuivre I'eK^cution du 
^.o.^HA en etape 46 si la procedure scalaire a. M 
5 declench^e a partir de I'^tape 44, en etape 56 si la 
procedure scalaire a M d^clench^e ^ partir de I'^tape 55 
ou en 6tape 60 si la procedure scalaire a 6te d^clench^e a 

partir de 1' etape 59. 

La procedure de cloture est decrite a . present en 

10 reference a la figure 6. 

Dans une 6tape 62, le traducteur 10 insere une 
definition d' element constitue d'un couple (type, 
longueur) au debut du patron dont le nom local Def Ticket_X , 
correspond au nom DefTicket_ObjetRoot si la procedure est 
d^clenchee a partir de I'^tape 46. et au nom 
DefTicket_Table_Ti si la procedure" de cloture est 
declench^e a partir de 1' etape 60. 

Dans une 6tape 63, le tradudteur 10 affecte la valeu^r 
de la variable nomm^e localement "Template_X_ID". au 
premier terme et le num6ro du champ courant au deuxi^me 
terme de la definition de l'616ment insere en 6tape 62.- 
Comme precedemment , X est remplac^ par "ObjetRoot" ou 
"Table_Ti" selon le cas d'appel de la procedure. La valeur 
de type affectee au premier terme constitue uri identifiant 
du patron parmi les patrons standards crees , Le numero du 
champ affecte au deuxieme terme, , donne une longueur de 
patron, exprim^e ' en . quantite de champs correspondant 
chacun ^ un couple (type, longueur) relatif a un objet 
traite dans la procedure scalaire ou dans la procedure 
30 table selon le cas. I 
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Dans une etape 64, le traducteur 10 insert une 
definition d' Element constitute d'un couple (type, 
longueur) au debut du patron qui resulte de I'ttape 62 et 
dont le nom DefTicket_X correspond au meme nom de patron 

que dans 1' 6tape 62 . 

Dans une etape 65, le traducteur 10 affecte la valeur 
de la constante de definition de patron de 1' etape 40, au 
premier terme de la definition de 1' element insere en 
6tape 64. La valeur 2 par exemple, indique que la suite de 
couples g6ner6e, est un patron de MIB. Le traducteur 10 
ajoute 2 au numtro du champ courant de fapon a prendre en 
compte les deux champs correspondant chacun respectivement 
au couple ins6r6 en etape 62 et au couple insure en etape 
64. Lorsque chaque terme de couple est constitu6 par 
exemple- d' un mot de deux octets, le traducteur 10 
multiplie le rtsultat pr6cedemment obtenu par 4 de fagon a 
obtenir une longueur de patron exprimte en octets qui est 
alors affectte au second terme du couple insert en 6tape 
64. 

Dans une ttape 5, le traducteur 10 enregistre le 
patron standard ainsi obtenu dans la memoire de masse 14. 

One 6tape 24 consiste a tester si une creation de 
patron de configuration a ete demandte, c'est a dire si le 
parametre Gtc en abrege, est 6gal a 1- Une reponse 
25 negative provoque le retour immediat de la procedure, 
aucun ):..^.t3;oP d* configuration ri'etcint 3 creer. 
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configuration, n'est modifiable, le nombre de champs reste 
nul et il n'y a alors pas lieu d' enregistrer un patron de 

configuration. 

Une r^ponse positive au test de I'^tape 25, d6clenche 
5 une suite d'etapes 26 a 29 qui se termine par I'^tape 5 
pour enregistrer un . patron de configuration avant le 
retour de procedure, 6tant constat^ qu'il existe au moins 
un champ correspondant a un objet modifiable. 

Dans I'^tape 26, le traducteur 10 insere une 
10 definition d'el^ment constitue d'un couple (type, 
longueur) au d^but du patron dont le nom local 
DefTicket_Configuration_X correspond au nom 

DefTicket_Configuration_ObjetRoot si la procedure est 
d^clench^e a P^rtir de I'etape 46 et au npm . 
15 DefTicket_Conf iguration_Table_Ti , si la procedure de 
cloture est d6clench6e a partir de, I'etape 60. 

Dans l'6tape 27, le traducteur 10 af facte la valeur 
de la variable nomm^e localemept 

"Template_Configuration_X_ID" au premier terme et. le 
20 nombre de champs courant au deuxifeme terme de la 
definition de 1' element ins6r6 en , 6tape 26. Comme . 
pr^cedemment, X est remplace par "ObjetRoot" ou "Table_Ti" 
selon le cas d'appel de la procedure. La valeur de type 
affectee au premier terme constitue un id^ntifiant du 
25 patron parmi les patrons de configuration crees . Le nombre 
de champs affect^ au deuxi^me terme, donne une longueur de 
patron, exprim6e ■ en' quantity de champs correspondant 
chacun ^ un couple (type, longueur) relatif a un objet 
traits dans la procedure scalaire ou dans la procedure 
30 table selon le cas. ^ 
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Dans I'etape 28, le traducteur 10 insert une 
definition d' element constitute d' un couple (type, 
longueur) au debut du patron qui resulte de I'^tape 27 et 
dont le nom Def Ticket_Conf iguration_X correspond au m§me 
5 nom de patron que dans I'etape 26. 

Dans I'ttape 29, le traducteur 10 affecte la valeur 
de la constante de definition de patron de I'etape 40, au 
premier terme de la definition de 1' element insert en 
etape 64. La valeur 2 par exemple, indique que la suite de 
10 couples generee, est un patron de MIB. Le traducteur 10 
a j cute 2 au num6ro du champ courant de fa?on k prendre en 
compte les deux champs correspondant chacun respectivement 
au couple ins6r6 en etape 26 et au couple insert en 6tape 
28. Lorsque chaque terme de couple est constitue par 
15 exemple d'un mot de deux octets, le traducteur 10 
raultiplie le r6sultat pr^cedemment obtenu par 4 de fagon k 
obtenir une longueur de patron exprim^e en octets qui est 
alors affectee au second terme du couple insert en etape 
64. 

20 Dans I'etape 5, le traducteur 10 enregistre le patron 

de configuration ainsi obtenu dans la memoire de masse 14. 

Le module 13 de typage nommage execute le precede 
decrit a present en reference a la figure 7. 

Dans une etape 70, le module 13 regoit I'OID de 
25 I'objet, le type de I'objet, le sous-type de I'objet, la 
tailli minimale de I'objet. U-. t.?ill'? raa;:imc-.l* ■:l~r 1' .>bj.r:i:, 



23 



10 



15 



champ courant re<?u en 6tape 70. Cette 6tape permet au 
module 13 de transmettre un type par d^faut qui est le 
num6ro de champ courant dans le patron standard. 

Dans une 6tape 72, le module 13 cree une variable 
nommee longueur_champ_template et lui affecte la taille 
maximale de I'objet regu en etape 70. Cette etape permet 
au module 13 de transmettre. une longueur par defaut qui 
est la . longueur maximale que peut avoir un champ pour 

I'objet courant. 

• Dans une 6tape 73, le module 13 teste s ' il existe un 
sous-type SMI pour I'objet courant. Une reponse positive 
au test declenche une etape 74 et une reponse negative au 
test declenche une §tape 75. 

Dans 1' etape 74, le module 13 determine la longueui^;. 
maximale du sous-type SMI et affecte cette longueur ^ la, 
variable longueur_champ_template. 

L'6tape 75 consiste a tester si une regie de. 
traduction associe un type de champ de patron ^ I'objet. 
correspondant a I'OID regu ou ^ son., type SMI ou k son 
sous-type SMI. Une reponse positive au test declenche une 
etape 76. Une reponse negative au test declenche une 6tape, 
* 7 8 

Dans 1- etape 76, le module 13 affecte alors le type 
de champ procure par la regie, a la variable 
25 "type_champ_teiripiate" . 

Dans .une etape 77, le module 13 . affecte la longueur 
de ce type de • champ./ a ' la variable nommee 
"longueur_champ_template". De plus, s'il existe une regie 
de traduction assoeiant une restriction de longueur a 
30 I'objet correspondant S I'OID regu, alors cette longueur 
est affect^e k la variable "longueur_champ_template" . 
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Dans I'etape 78, le module 13 transmet au traducteur 
10, un couple (type, longueur) dont la premiere valeur est 
celle de la variable "type_champ_teinplate" et dont la 
deuKi&iue valeur est celle de la variable 
"longueur_champ_template" . 

Le proc6d6 en action va maintenant §tre decrit A 
partir d'un exemple d'objet qui est une table connue 
"bufferControlTable" en r^f^rence aux figures 8 a 10 et 
d'un exemple d'objet qui est une autre table connue 
"AalSVccTable" en reference aux figures 11 a 13. 

La figure 8 est une representation d'arbre pour une 
table de MIB dont 1' annexe 1 donne un extrait de 
definition SMI que I'on peut trouver plus detaill6e aux 
pages 75 ^ 77 de la RFC2819 disponible sur le site 
15 Internet http: //www.ietf -org. 

La premiere colonne a gauche du tableau donne un 
numero de noeud (OID pour Object Identifier) ref^rengant un 
Ob jet nomme en deuxieme colonne avec son type en troisieme 
colonne et sa longueur en quatrieme colonne. La derniere 
colonne a droite donne une longueur de sous type s'il en 
existe un. La suite de premiers chiffres du num6ro de noeud 
1.3.6.1.2.16. donne la localisation d'une MIB 11 dans 
1-arborescence des MIBs. Le chiffre 8.1. suivant indique 
la localisation de I'objet "BufferControlTable" dans cette 
MIB. L'arborescence des objets de la table est donn^ par 
1-5S chiffres 1.1 1.13. 
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Lorsque le traducteur 10 parcours I'arbre de la MIB 
11 ref6rencee 1.3.6.1.2.1.16.8 en m^moire 12, il rencontre 
en etape 44, I'objet "buf ferControlTable" qui est une 
table r^ferencee 1.3.6.1.2.1.16.8.1 en memoire 12. Le 
5 traducteur 10 execute alors la procedure table pour 
laquelle nous supposons par exemple que la variable 
"current_teniplate_ID" vaut 302 a ce moment en 6tape 30. 

En 6tape 31, la variable "current_template_ID'' est 
raise k 303. En etape 51, le traducteur 10 cr6e le patron 
10 de la figure 9, initialement vide. On suppose qu ' en etape 
19 "G6n6ration_templates_con,figuration" vaut zero pour 
siinplifier. En 6tape 23, la variable "current_template_ID" 
vaut alors 304. En 6tape 52, la variable.. 
"num6roDuChampCourant_DefTicket_Table_Ti" vaut zero. 
15 En 6tape 55, . le traducteur 10 rencontre I'objet 

"buffercontrollndex" pour lequelil execute la procedure 
scalaire. 

^.^ AH la variable 

En 6tape. 48, 

"nuraeroDuChampCourant_DefTicket_Table_Ti" vaut 1. • 
20 En etape 49, la definition SMI de I'objet donne le 

type integer 32 avec un sous type de taiHe maximale de 2.- 
En etape 8, le module de typage retourne un couple de 
valeur (1,2). En 6tape 50, le traducteur 10 ajoute le 
couple (1,2) sous. forme de deux mots binaires . 121 chacun 
25 de deux octets au patron de la figure 9. 

A la suite des,6tapes 56 et 57, en etape 55, le 
traducteur ' IP ' ' rencontre I'objet 

"bufferControlChannellndex" pour lequel il execute la 
procedure scalaire. 

^ la variable 

30 En etape 48, 

"numeroDuChampCourant_DefTicket_Table_Ti" vaut 2. 
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En etape 49, la definition SMI de I'objet donne le 
type Integer32 avec un sous type de taille maximale de 2. 
En etape 8, le module de typage retourne un couple de 
valeur (2,2). En etape 50, le traducteur 10 ajoute le 
5 couple (2,2) sous forme de deux mots binaires 122 chacun 
de deux octets au patron de la figure 9. 

A la suite de 1 ' 6tape 56, le traducteur 10 rencontre 
k nouveau les deux objets precedents et passe directement 
k I'objet suivant en 6tape 61. 
10 En 6tape 58, le traducteur 10 rencontre I'objet 

"bufferControllFullStatus" pour lequel il execute la 
procedure scalaire. 

En 6tape 48, la variable 

"num6roDuChampCourant_DefTicket_Table_Ti" vaut 3. 
15 En etape 49, la definition SMI de I'objet donne le 

type INTEGER avec un sous type de taille de 2. En 6tape 8, 
le module de typage retourne un couple de valeur (3,2). En 
etape 50, le traducteur 10 ajoute le couple (3,2) sous 
forme de deux mots binaires 123 chacun de deux octets au 
20 patron de la figure 9. 

On peut r^iterer les explications prec6dentes pour 
chaque objet suivant du tableau de la figure 8, le 
traducteur 10 ajoutant alors en 6tape 50, pour chacun 
rencontre en etape 58, respectivement le couple (4,2), 
25 (5,2), (6,2), (7,4), (8,4), (9,4), (10,4), (11,4), 
( I.:, 32), 1 12,-1) sous forme respective >!'^ 0~u:: mr^'r^ 
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d-une suite de couples de mots 121 ^ 133. Le traducteur 10 
execute la procedure de cloture. 

• En etape 62, le. traducteur 10 ajoute un couple de 
hinaires 120 au d^but du patron. En 6tape . 63, le 
5 traducteur 10 affecte la valeur 302 au premier mot et la 
valeur 13 au deuxieme mot du couple. 

En 6tape 64, le traducteur 10 ajoute un couple de 
mots binaires 119 au d6but du patron. En 6tape 65, le 
traducteur 10 affecte la valeur 2 au premier mot et la 
10 valeur 60 au deuxieme mot du couple. 

En etape 5, le traducteur 10 enregistre le patron tel 
qu'il se pr^sente au final en figure 9. 

Le patron de la. figure 9 permet de transmettre des 
tickets de donn^es dont les valeurs sont contenues dan^: 
15 des lignes de la table "buf ferControlTable" . 

■ La figure 10 montre un exemple de ticket de donnees.-.: 

1 = 1-5 rrn*» 34 de la table donne ies valeurs, ' 
Supposons que la ligne J4 ae i<a "-a 

* ■ 

suivantes: ■• 

- bufferControlIndex Z IAa 

■ 20 - buf ferControlChannellndex , Z % ' 

- bufferControlFullStatus ' I Lo 

- bufferControlFullAction - 

■•- bufferControlCaptureSliceSize - 512 

- bufferControlDownloadSliceSize = 200 
25 - bufferControlDownloadOffset - 

- buf ferControlMaxOctetsRequested= lOOOO^OOO . 

- bufferControlMaxOctetsGranted = 1000000 

- bufferControlCapturedPackets = ^0000^ 

- bufferContirolTurnOnTime ^ 34547 643b4 
30 - buf ferControlOwner . • ' ~ 

- buf f erControlStatus 3 

Dans le ticket de donnees correspondant de la figure 
■ 10 un mot 99 de deux octet contient la valeur 302 qui 
rei^rence le patron de la figure 9. Un mot 100 de deux 
35 octet contient la valeur 72 qui repr^sente la longueur 
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cumulee des 13 champs de donn^es indiqu6s par le patron de 
la figure 9 avec les deux mots 99 et 100, soit la longueur 
totale du ticket de donnees. 

Ensuite des champs 101 S 106 dont la longueur de 
5 chacun est donnee respectivement par le deuxieme mot des 
couples 121 a 126 du patron, contiennent respectivement 
les valeurs 34, 654, 2, 542, 512 et 200. Des champs 107 a 
111 dont la longueur de chacun est donnee respectivement 
par le deuxieme mot des couples 127 a 131 du patron, 
10 contiennent les valeurs 32, 100000000, 1000000 et 
34547 64364. Un champ 112 dont la longueur est donn6e par 
le deuxieme mot du couple 132, contient la chalne de 
caractere acme par exemple cod6e en ASCII. Un champ 113 
dont la longueur est donnee par le deuxieme mot du couple 
15 133, contient la valeur 3. 

Pour chaque valeur de champ du ticket de donnee, le 
type donn6 par le premier mot de chacun des couples 121 k 
133 du patron, permet a un destinataire du ticket de 
reconnaitre a quel objet cette valeur appartient. 
20 On notera I'^conomie de bande passante et la 

simplification de calcul que permet 1' usage des tickets de 
donnees. Les donn6es d'entete de message SNMP ne sont pas 
pris en compte. Le ticket de donnees de la figure 10 ne 
contient que quatre octets d'entetes, les deux premiers 
25 pour ref^rencer le patron correspondant et les deux 
.l^.-rni.3rs pour en indiquer la longu^sur facon ?. 
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triplet (objet identifier + index value, longueur, valeur) 
par objet oCi "objet identier" est I'OID d'un champ de 
table, index- value est la valeur de 1' index 
Rnffe.rControlIndex pour identifier plus pr6cisement une 
instance de I'objet, c'est a dire 12* (11+2) octets soit 
156 octets. La reponse aurait necessite en plus les 30 
octets de valeurs,- soit 186 octet s. 

En comparaison des 72 octets du ticket de donnees, 
SNMP est done beaucoup plus gourmand en messages et 
surtouf en debit puisqu'il genere quatre fois plus de 
trafic. II est vrai que le transfert de donnees par ticket 
necessite une transmission prealable de patron qui dans 
I'exemple pr6c6demment d^crit de la figure 9, represents 
60 octets, ramenant a une generation seulement deux fois: 
moindre de trafic pour une transmission de premier ticket 
en" comparaison de SNMP. Cependant, un mSme patron peut 
etre utilise pour des tickets successifs sans avoir besoin 
d'etre transmis a nouveau, r^duisant ainsi le trafic dans 

une proportion de 2 ^ 4 . . 

La figure 11 est une representation d'arbre pour une 
table de la MIB ATM dont 1' annexe 2 dpnne un extrait de- 
definition SMI que I'on peut trouver plus d^-tailiee aux 
pages 61 a 63 de la RFC1695 disponible sur le site 
Internet http://www.ietf.org. 

La-' premiere colonne k gauche du tableau donne un 
numero de^' noeud r6feren?ant un objfet nomme en deuxi^me 
colonne avec son type- en troisieme colonne et sa longueur 
en quatrieme colonne. La derniere colonne donne la 
■ longueur du sous type si elle existe. Le numero de nceud 
) dans I'arborescence g6n6rale des MIBs, est encore appel6 
OID (Object Identifier) . La suite de premiers chif fres du 
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num^ro de nceud 1.3.6.1.2.1.37 donne la localisation de la 
MIB ATM dans 1 ' arborescence des MIBs. Le chiffre 1.12. 
suivant indique la localisation de I'objet "aalSVccTable" 
dans la MIB ATM. Une arborescence des objets de la table 

5 est donnee par les chiffres 1.1 a 1.5. 

Dans la specification SMI de 1 ' annexe 2, 1 " index de 
la table est constitu6 de trois objets "if Index", 
"aalSVccVpi" et "aalSVccVci" . Les deux derniers objets 
appartenant a la table consideree. Le premier objet 

10 appartient a la table "if Table" d'une autre MIB relative 
aux interfaces physiques, connue sous le nora de MIBII et 
localis^e dans 1 ' arborescence des MIBs par les chiffres 
1.3.6.1.2.1. Le chiffre 2.2 localise la table dans la MIB 
II L' objet "if Index" quant a lui est localise par les 

15 chiffres 1.1. dans la 1 • arborescence de la table 
"if Table". 

A partir de la definition SMI de 1' annexe 2 et de la 
MIB II en etape 3, le traducteur 10 construit un arbre de 
noiranage en memoire 5. Get arbre est d^fini a partir des 
20 chiffres des OID de la figure 11. 

La figure 12 montre un exemple de patron standard 
dont la generation par le precede est ^ present d6crite. 

Lorsque le traducteur 10 parcoure le sous arbre 
1.3.6.1.2.1.37 de 1" arbre const itue de la MIB II et de la 
25 MIB ATM en memoire 12, il rencontre en etape 44, I'objet 
"aalbVccTabi'X'" qui est une t:able ref -ir-rincee 
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En §tape 31, la variable "current_template_ID" est 
xnise a 304. En 6tape 5l/ le traducteur 10 cree le patron 
de la figure 12, initialement vide. On suppose qu'en etape 
19, "Generation_templates_configuration" vaut z^ro pour 
simplifier. En 6tape 23, la variable "current_teinplate_ID" 

-^rsd c«„ e.-haT-><3 52. la Variable 
vaut alors 305. En • etape o^. 

"num6roDuChampCourant_DefTicket_Table_Ti" vaut z6ro. 

En §tape 55, le traducteur 10 rencontre I'objet 
"if index", premier terme del' index, pour lequel il 

execute la procedure scalaire. 

AO la variable 

En etape 48, 

"num6roDuChainpCourant_DefTicket_Table_Ti" vaut 1. 

En etape 49, la definition SMI de I'objet donne le 
type INTEGER avec une taille maximale de 4 . En etape 8, le . 
module de typage retourne un couple de valeur (1,4). En 
6tape 50, le traducteur 10 ajoute le couple (1,4) sous 
forme de deux mots binaires 81 chacun de deux octets au- 

patron de la figure 12. 

A la suite des etap^s 56 et 57, en 6tape 55., .le 
traducteur 10 rencontre I'objet "aal5VccVpi" , deuxi^me 
terme de 1' index, pour lequel il execute la procedure, 
scalaire. 

En 6tape 48, la variable 

"numeroDuChampCourant_DefTicket_Table_Ti" vaut 2. 

' En^tape 49, la definition SMI de I'objet donne le 
type Atmvpldentifier avec un sous type de taille maximale 
de 2. En etape 8, le.module de typage retourne un couple 
de valeur (2,2). En etape 50, le traducteur 10 ajoute le 
couple (2,2) sous forme de deux mots binaires 82 chacun de 
deux octets au patron de la figure 12. ^ 



ler d6p6t 

32 



A la suite des Stapes 56 et 57, en etape 55, le 
traducteur 10 rencontre le troisi^me terme de 1' index, 
1- Ob jet "aalSVccVci" pour lequel il execute la procedure 
scalaire . 

5 En 6tape 48, la variable 

"numeroDuChampCourant_DefTicket_Table_Ti" vaut 3. 

En 6tape 49, la definition SMI de I'objet donne le 

type AtmVcIdentifier avec un sous type de taille maximale 

de 2. En 6tape 8, le module de typage retourne un couple 
10 de valeur (3,2). En 4tape 50, le traducteur 10 ajoute le 

couple (3,2) sous forme de deux mots binaires 83 chacun de 

deux octets au patron de la figure 12 . 

A la suite de l'6tape 56, le traducteur 10 rencontre 

a nouveau les trois objets pr6c6dents et passe chaque fois 
15 directement k I'objet suivant en etape 61 en passant par 

les stapes 58, 59, 60 et 61. 

En etape 58, le traducteur 10 rencontre I'objet 

"aalSVccCrcErrors" pour lequel il execute la procedure 

scalaire . 

20 En 6tape 48, la variable 

"num^roDuChampCourant_DefTicket_Table_Ti" vaut 4. 

En etape 49, la definition SMI de I'objet donne le 
type Counter32 avec une taille maximale de 4 . En etape 8, 
le module de typage retourne un couple de valeur (4,4). En 

25 etape 50, le traducteur 10 ajoute le couple (4,4) sous 
form.: -He deu:: mote binaires G4 chacun de ..leu:-: octets au 
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,6,4), sous forme respective de deux mots binaires 85, B6, 
chacun de deux octets au patron de la figure 12. 

■ Apr^s attelnte de I'objet "aalSVccOverSxzedSDUs en 
60, le patron de la figure 12 est alors constitu. 
suite de couples de mots 81 4 86. Le traducteur 10 
exAoute la procedure de cl6ture. 

En .tape 62, le traducteur 10 , ajoute un couple de 
mots blnaires 80 au d*but du patron. En *tape 63 le 
traducteur 10 affecte la valeur 303 au premier mot et 
I valeur 6 au deuxiferae mot du- couple. 

En «ape 64, le traducteur 10 ajoute un couple de 
mots blnaires 79 au d*but du patron. En etape 65 le 
traducteur 10 affecte la valeur 2 au premier mot et la 
valeur 32 au deuxitoe mot du couple. 
5 En 6tape 5, le traducteur 10 enreglstre le patron tel 

au'il se pr6sente au final en figure 12. • 
Le patron de la figure 12 permet de transmettre des 

^ *. Tral^urs sont contenues dans 

tickets de donnees dont les valeurs 

la table "aalSVccTable".. Les tickets . sont 
des Ixgnes de la taoxe s« ^ - i &t-r*» 

1^1 «^ ria i-i f kets destxne a etre 
10 g^neralement regroup4s par bloc.de tickets 

emis vers un collecteur. , . 

. ■ ^ figure 13 montre un exetr^le de ticket de donn*es. 

Supposons ,ue la llgne de la table d.orivant la gualite du 
trafic du circuit MM transitant par V interface 12 et 

• 1- virtuel correspondant au Vci 
25 . identifie comme le circuit virtuei 

1000 du Vpi 100, donne les valeurs suivantes: 

- if Index ' . = 1? 

- aalSVccVpi = 100 . 

- aalSVccVci Z - ='100° 

30 - aalSVccCrcErrors = 15432 ^ 

- aalSVccSarTimeOuts =456 
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- aalSVccOverSizedSDUs = 567 

Dans le ticket de donnees correspondant de la figure 
13, un mot 199 de deux octet contient la valeur 303 qui 
reference le patron de la figure 12. Un mot 200 de deux 
5 octets contient la valeur 24 qui represente la longueur 
cumulee des 6 champs de donnees indiques par le patron de 
la figure 9 avec les deux mots 199 et 200, soit la 
longueur totale du ticket de donnees . 

Ensuite des champs 201 a 206 dont la longueur de 
10 chacun est donn^e respect ivement par le deuxidme mot des 
couples 81 k 86 du patron, contiennent respect ivement les 
valeurs 12, 100, 1000, 15432, 456 et 567. 

Pour chaque valeur de champ du ticket de donn6e, le 
type donne par le premier mot de chacun des couples 81 a 
15 8 6 du patron, permet a un destinataire du ticket de 
reconnaltre a quel objet cette valeur appartient. 

On notera la encore I'^conomie de bande passante et 
la simplification de calcul que permet 1' usage des tickets 
de donnees . 

20 En reference a la figure 14, un systeme de mesure 91 

comprend des sondes 8 9 de mesure de performances de 
reseaux IP et un controleur systeme 90 auquel sont 
connectees les sondes 89. 

Un agent SNMP 93 met en ceuvre la MIB 11 IPPM 

25 REPORTING MIB en mode delegu6 (proxy en anglais) . Elle est 
def ini'3? dans ivvw. letf . oro /h 'cm] . »vi-'.=i j.act^rrs /'iDpm- 
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peuvent alors consulter les mesures en cours et leurs 
resultats en utilisant le protocole classique SNMP. 

' On salt que 1' interface connue de gestion IPPM 
REPORTING MIB definit plusieurs tables dont les tables 

5 ippmNetworkMeasureTable et ippmHistoryTable sont retenues 
ici k titre d' example pour illustrer un usage industriel 
du precede objet de 1' invention. La table de mesure reseau 
95 nominee ippmWetworkTable porte des definitions de 
mesures mises en place entre les " sondes par un superviseur 

10 87 h6berge dans le controleur 90. Le superviseur 87 
effectue la collecte des resultats de mesures en 
provenance des sondes 89. La table historique 96 nommee 
IppmHistoryTable stocke les resultats des mesures regues 
du superviseur. L' agent 93- comprend une copie de ces deuj?.. 

15 tables parmi d'autres. 

De fagon ^ pouvoir utiliser le procede precedemment.. 
d§crit, le systfeme 90 est conforme ^ la representation de. 
la figure 1. On retrouve sur la figure 14, le traducteur. 
10 et la specification de MIB 11. Le traducteur 10 a ici 
20 pour fonction entre autres, de gen^^rer des patrons pour 
les tables ippmNetworkTable et ippmHistoryTable. 

Le systeme 91 comprend aussi un . module 88 
d' exportation de patrons et de tickets de donn^es. Le 
serveur delegue 92 comprend un module 18 de reception de 
25 patrons et de tickets de donnees. Pour communiquer, les 
modules 18 et 88 utilisent un pfotocole nomme IPFIX, 
specialement adapts aux echanges de patrons et de tickets 

entre modules. 

Le serveur del^gu^ 92 comprend aussi ou a acces a urie 
30 instance du traducteur 10 et de la MIB 11. Ainsi lorsque 
le systeme 91 envoie un patron au serveur deiegue 92 au 
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moyen du module 88, le serveur delegue 92 recevant ce 
patron au moyen du module 18, peut se preparer a recevoir 
des tickets de donnees contenant les descriptions et les 
resultats de mesures emises a la suite du patron par le 

5 systeme 91- Le serveur delegue 92 comprend un module 17 
auquel le traducteur 10 permet de faire correspondre les 
champs du patron aux definitions SMI d'objets pour 
alimenter 1^ agent 93 en tables et en objets en concordance 
avec les valeurs qui seront regues dans les tickets de 

10 donnees. 

Ensuite^ le systeme de mesure 91 utilise le protocole 
IPFX pour remettre au fil de I'eau les mesures mises en 
place et les resultats de ces mesures, au serveur delegue 
92. La station 94 peut alors recevoir les mesures de 
15 1' agent 93 de fagon classique par le protocole SNMP. 

La figure 15 donne un exemple de patron de la table 
ippmHistoryTable obtenue dans le systeme 91 au moyen du 
precede precedemment decrit. Ici les valeurs dans les 
differents champs sont exprimees en decimales pour en 
20 faciliter une lecture rapide, sachant qu'elles sont 
exprimees en realite sous forme binaire. 

Le premier et le deuxieme mot du couple 139 
contiennent respectivement la valeur 2 pour indiquer que 
la structure de donnees est un patron et la valeur 36 
25 indiquant en octets la longueur du patron. 

Le premier '^t le cleu;:i^^rne mot -'^u couple l-'IO 
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respectivement la valeur 1 pour indiquer le type de champ 
et la valeur 32 indiquant en octets la longueur du champ. 

■ Le premier et le deuxieme mot du couple 142 relatif k 
1' Ob jet "ippmHistoryMeasurelndex", contiennent 

respectivement la valeur 2 pour indiquer le type de champ 
et la valeur 4 indiquant en; octets la longueur du champ. 

Le premier et le deuxieme mot du couple 143 relatif a 
1' Ob jet "ippmHistoryMetricIndex", contiennent 

respectivement la valeur 3 pour indiquer le type de champ 
et la valeur 4 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 144 relatif k . 
I'objet "ippmHistorylndex", contiennent respectivement la 
valeur 4 pour indiquer le type de champ et la valeur 4 
indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 145 relatif av 
I'objet "ippmHistorySequence",. contiennent respectivement: 
la valeur 5 pour indiquer le type de champ et la valeur 4, 
indiquant . en octets la. longueur du champ . ••; 

Le premier et le deuxieme mot du couple 146 relatif k 
I'objet "ippmHistoryTimestamp", contiennent respectivement 
la valeur 6 pour indiquer le type de champ et la valeur 8 ■ 
indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 147 relatif k 
I'objet "ippmHistoryValue", contiennent respectivement la 
valeur -1 pour indiquer le type de champ et la valeur 4 
indiquant en octets la longueur du champ. 

La figure 16 doniie un exemple de ticket de donnees de 
la table. ippmHistoryTable obtenue dans le systeme 91 pour 
§tre lisible au moyen du patron de la figure 15. Comme 
c'est le cas pour les autres figures de patron ou de 
ticket de donnee, une largeur de ligne repr6sente quatre 
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octets, une hauteur de ligne n'est cependant pas 
proportionnelle au nombre d' octets pour un champ de plus 
de huit octets de fa?on a faire tenir la representation de 
la figure sur un nombre de pages raisonnable. 

5 Le premier champ 14 9 contient sur deux octets, la 

valeur 304 qui est celle du premier mot du couple 140 dans 
le patron correspondant . 

Le deuxieme champ 150 contient sur deux octets la 
valeur 64 pour indiquer la quant ite d' octets du ticket de 

10 donnees. 

Le champ 151 relatif a I'objet 

"ippmHistoryMeasureOwner", contient la chaine de 
caracteres FTRD codee en binaire, 

Le champ 152 relatif a I'objet 

15 "ippmHistoryMeasurelndex", contient la valeur 5 qui indexe 
la mesure et la valeur 6 qui indexe un delai d'aller 
simple . 

Le champ 153 relatif ^ I'objet 

"ippmHistoryMetricIndex", contient la valeur 6 qui indexe 
20 le type de metrique mesure, en 1' occurrence 6 correspond a 
un delai unidirectionnel . 

Le champ 154 relatif a I'objet "ippmHistorylndex" , 
contient la valeur 123 pour indiquer que le r6sultat de la 
mesure transmis dans ce ticket, est le 123ieme. 
25 Le champ 155 relatif a l^objet "ippmHistorySequence" , 

contient la valeur lO'I:'^ 50205^ pour indiquer •■fU'^ 1-^ mesure 
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representative d'une part f ractionnelle d' estampillage 
temporal . 

■ Le champ 157 relatif k I'objet "ippmHistoryValue" , 
contient la valeur 567 qui est celle de la mesure de 
d61ai, l'unit6 6tant donn^e par le champ 152. 

La figure 17.donne un" exemple de patron de la table 
ippmNetworkTable obtenue dans le systfeme 91 au moyen du 
precede pr^cedemment decrit. Ici encore les valeurs dans 
les diff6rents .champs sont exprimees en decimales pour en 
faciliter une lecture rapide, sachant qu'elles sont 
exprimees en realite sous forme binaire. 

Le premier et le deuxifeme mot du couple 159 
contiennent respectivement la valeur 2 pour indiquer que 
la structure de donn^es. est un patron de MIB et la valeur • 
116 indiquant en octets la longueur du patron. ■ 

■ Le premier et le deuxieme mot du couple 160 
contiennent respectivement la vaieur 302 pour indiquer que. 
le patron est relatif k la table des mesures r^seau et la 
valeur 27 indiquant la quantity de champs, de donn6es. 

20 formates par le patron. 

Le premier et le deuxieme mot du couple 161 relatif ^' 
■ 1 • Ob j et " ippmNetwor kMeasureOwner " , - contiennent 

respectivement la valeur 1 pour indiquer le type de champ 
et la valeur 32 indiquant en octets la longueur. du champ. 

Le premier et le deuxieme mot du couple 162 relatif ^ 
1 ' objet "ippmNetworkMeasurelndex" , contiennent 

respectivement la valeur 2 pour indiquer le type de champ 
et la valeur 2 indiquant en octets la longueur du champ. 

Le premier, et le deuxieme mot du couple 163 relatif k 
30 1' objet "ippmNetworkMetricName", contiennent 
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respectivement la valeur 3 pour indiquer le type de champ 
et la valeur 256 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 164 relatif a 
1 ' ob j et "ippmNetwor kMeasureMetrics " , contiennent 

5 respectivement la valeur 4 pour indiquer le type de champ 
et la valeur 8 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 165 relatif a 
I'objet "ippmNetwor IcMeasureBeginTime"^ contiennent 

respectivement la valeur 5 pour indiquer le type de champ 

10 et la valeur 4 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 166 relatif a 
1 ' objet "ippmNetworkMeasureCollectionRateUnit", 
contiennent respectivement la valeur 6 pour indiquer le 
type de champ et la valeur 4 indiquant en octets la 

15 longueur du champ - 

Le premier et le deuxieme mot du couple 167 relatif a 
1 • objet "ippmNetworkMeasureCollectionRate", contiennent 
respectivement la valeur 7 pour indiquer le type de champ 
et la valeur 4 indiquant en octets la longueur du champ. 

20 Le premier et le deuxieme mot du couple 168 relatif a 

1 ' ob j et " ippmNetwor kMeasureDurationUnit " , contiennent 
respectivement la valeur 8 pour indiquer le type de champ 
et la valeur 4 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 169 relatif a 

25 1 • ob j et " ippmNetwor kMeasureDurat ion" , contiennent 

*j-^,^.pert: ivement la valeur pour indiqu-er I'r tyo^ ile champ 
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Le premier et le deuxieme mot du couple 171 relatif k 
I'objet "ippmNetworkMeasureFailureMgmtMode", contiennent 
respectivement la valeur 11 pour indiquer le type de champ 
et la valeur 4 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 172 relatif ^ 
I'objet "ippmNetworkMeasureResultsMgmt", contiennent 
respectivement la valeur 12 pour indiquer le type , de champ 
et la valeur 4 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 173 relatif ^ 
I'objet "ippmNetwprkMeasureScrcTypeP", contiennent 

respectivement la valeur 13 pour indiquer le type de champ 
et la valeur 512 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 174 relatif a,. 
I'objet "ippmNetworkMeasureScrc", contiennent 

respectivement la valeur 14 pour indiquer le type de champ 
et la valeur 512 indiquant en octets la longueur du champ,. 

Le premier et le deuxieme mot du couple 175 relatif a 
I'objet "IppmNetworkMeasureDstTypeP';, contiennent 

respectivement la valeur .15 pour indiquer le type de champ 
20 et la valeur 512 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 176 relatif k' 
1. Ob jet "IppmNetworkMeasureDst", 'contiennent 

respectivement la valeur 16 pour indiquer le type de champ 
et la valeur 512 indiquant en octets la longueur du champ. 

Le: premier et le deuxieme mot du couple 177 relatif ^ 
1 ' Ob jet "ippmNetworkMeasureTransraitMode" , contiennent 
respectivement la valeur 17 pour indiquer le type de champ 
et la valeur 4 indiquant en octets la longueur du champ. 

Le premier et le" deuxieme mot du couple 17 8 relatif k 
1 ' ob j et " ippmNetwor kMeasureTransmit^acket Rat eUni t " , 

contiennent respectivement la valeur 18. pour indiquer le 



25 



30 



1 er depot 

42 



type de champ et la valeur 4 indiquant en octets la 
longueur du champ. 

Le premier et le deuxieme mot du couple 179 relatif k 
1' objet "ippmNetworkMeasureTransmitPacketRate", 
5 contiennent respectivement la valeur 19 pour indiquer le 
type de champ et la valeur 4 indiquant en octets la 

longueur du champ. 

Le premier et le deuxieme mot du couple 180 relatif a 
1" objet "ippmNetworkMeasureDeviationOrBurstsize", 
10 contiennent respectivement la valeur 20 pour indiquer le 
type de champ et la valeur 4 indiquant en octets la 
longueur du champ. 

Le premier et le deuxieme mot du couple 181 relatif ^ 
1' objet "ippmNetworkMeasureMedianOrlnterBurstsize", 
15 contiennent respectivement la valeur 21 pour indiquer le 
type de champ et la valeur 4 indiquant en octets la 
longueur du champ. 

Le premier et le deuxieme mot du couple 182 relatif a 
1' objet "ippmNetworkMeasureLossTimeout", contiennent 
20 respectivement la valeur 22 pour indiquer le type de champ 
et la valeur 4 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 183 relatif a 
1' objet "ippmNetworkMeasureL3PacketSize", contiennent 
respectivement la valeur 23 pour indiquer le type de champ 
25 et la valeur 4 indiquant en octets la longueur du champ. 

Le premier et le deur.ieme mo-t da .-cupl'i 134 .i.elatif a 
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respectivement la valeur 25 pour indiquer le type de champ 
et la valeur 256 indiquant en octets la longueur du champ. 

■ Le premier et le deuxi^me mot du couple 186 relatif a 
I'objet "ippmNetworkMeasureSingletons", contiennent 
respectivement la valeur 2 6 pour indiquer le type de champ 
et.la valeur 4 indiquant en octets la longueur du champ. 

Le premier et le deuxieme mot du couple 187 relatif k 
I'objet "ippmNetworkMeasureOperState", contiennent 

respectivement la valeur 27 pour indiquer le type de champ 
et la valeur 4 indiquant en octets la longueur du champ. 

La figure 18 donne un exemple de ticket de donn6es de . 
la table ippmNetworkTable obtenue dans le systeme 91 pour 
Stre lisible au moyen du, patron de la figure 17. 

Le premier champ 259 contient la valeur 302 qui est. 
celle du premier mot du couple 159 dans le patron 

correspondant . 

Le deuxieme champ 260 contient la valeur 2676 pour 
indiquer la longueur de ticket exprim^e. en octets. 

Le champ . 261 relatif . ^ I'objet 

"ippmNetworkMeasureOwner", contienf la chaine de 
caracteres FTRD codee en binaire pour indiquer le- 
propri^taire de la mesure. 

Le champ 262 relatif ^ I'objet 

"ippmNetworkMeasurelndex", contient la valeur 5 pour 
25 indiquer le num^ro de la mesure. 

Le •: champ . 263 relatif a I'objet 

"ippmNetworkMetricName"/ contient la chaine de caracteres 
"One-way-delay between Paris et Lannion" codee en binaire 
pour indiquer en clair ce quoi se rapporte la mesure. 
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Le champ 264 relatif ^ I'objet 

"ippmNetworkMeasureMetrics", contient la valeur 6 pour 
indiquer le type de mesure. 

Le champ 265 relatif ^ I'objet 

5 "IppmNetworkMeasureBeginTime", contient la valeur 
1034582058 pour indiquer que la mesure a debute le 14 
septembre 2003 a 9 heures 54 minutes 18 secondes . 

Le champ 266 relatif a I'objet 

"ippmNetworkMeasureCollectionRateUnit", contient la valeur 
10 0 representative d'une part fractionnelle d' estampillage 
temporel . 

Le champ 267 relatif a I'objet 

"ippmNetworkMeasureCollectionRate", contient la valeur 10 
pour indiquer le taux d' echantillonage . 
15 Le champ 268 relatif ^ I'objet 

"ippmNetworkMeasureDurationUnit", contient la valeur 6 
pour indiquer que 1 ' unit6 de dur^e de la mesure, est la 
seconde . 

Le champ 269 relatif ^ I'objet 

20 "ippmNetworkMeasureDuration", contient la valeur 120 pour 
indiquer que la mesure a dur6 120 secondes. 

Le champ 270 relatif ^ I'objet 

"ippmNetworkMeasureHistorySize", contient la valeur 1000 
pour indiquer la taille de I'historique de mesure. 
25 Le champ 271 relatif a I'objet 

'•ippiw^3tv^:>rV:Heasur«F3iluj;eHc!mtHu':l'=-'' . .:':'nt:iii.'t 1. -j ".nleur 1 
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Le champ 273 relatif a I'objet 

"ippmNetworkMeasureScrcTypeP", contient la chaine de 
caracteres "IP UDP", pour indiquer le protocole de 
trans fert utilise par la communication au depart de Paris 
5 qui fait I'objet de la mesure. 

Le champ 274; relatif ^ I'objet 

"ippmNetworkMeasureScrc", contient la valeur 8 0.168.0.1 
3456 pour indiquer I'adresse source de la communication, 
ici Paris. 

10 Le champ 275 relatif a I'objet 

"ippmNetworkMeasureDstTypeP", contient la chaine de 
caracteres "IP UDP" pour indiquer le protocole de 
transfert utilise par la communication a destination de 
Lannion qui fait I'objet de la mesure. 
15 Le champ-. 276 relatif k I'objet 

"ippmNetworkMeasureDst", contient la- valeur 180.168.0,1 
6543 pour indiquer I'adresse de destination de .la 
communication, ici Lannion. 

Le champ .. 277 relatif " a I'objet 

20 "ippmNetwbrkMeasureTransmitMode", contient la valeur 1 
pour indiquer que le mode de transmission est periodique. • 
Le champ 278 relatif ^ - I'objet 

"ippmNetworkMeasureTransmitPacketRateUnit", contient la 
valeur 6 pour indiquer que 1' unite de taux de paquets de 
25 64 octets transmis, est par seconde. 

Le .-."champ, 279 relatif a I'objet 

"ippmNetworkMeasureTransitiitPacketRate", contient la valeur 
100 pour indiquer que le taux d' Emission 6tait de 100 
paquets par seconde. 
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Le champ 280 relatif a I'objet 

"IppmNetworkMeasureDeviationOrBurstsize" , contient la 
valeur 0 pour indiquer une deviation nulle. 

r^H;=.Tnr^ relatif 3 1 ' obl et 

5 "ippmNetworkMeasureMedianOrlnterBurstsize", contient la 
valeur 0 pour indiquer une taille de rafale nulle. 

Le champ 282 relatif k I'objet 

"ippmNetworkMeasureLossTimeout", contient la valeur .15 
pour indiquer que le delai a 1' expiration duquel un paquet 
10 est consid6r6 perdu, est de 15 secondes. 

Le champ 283 relatif a I'objet 

"ippmNetworkMeasureL3PacketSize", contient la valeur 64 
pour indiquer que la taille des paquet s emis dans la 
communication qui fait I'objet de la mesure, est de 64 
15 octets. 

Le champ 284 relatif a I'objet 

"ippmNetworkMeasureDataPattern", contient la valeur FFFF 
pour indiquer le format des donnees de mesure. 

Le champ 28 5 relatif a I'objet 

20 "ippmNetworkMeasureMap", contient la chaine de caracteres 
"Reseau interne" pour indiquer en clair le type de r^seau. 

Le champ 28 6 relatif ^ I'objet 

"ippmNetworkMeasureSingletons", contient la valeur 0 par 
def aut . 

25 Le champ 287 relatif a I'objet 

"lppmiM-i:worl:l'ie3Sur€-0perC.tate", C'-.-r.-tierit: la valeui 0 ...a'- 
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comparaison de celle qui aurait M n^cessaire en 
utilisant le protocole SNMP ^ ce niveau. 

Le proc6d6 mis en ceuvre dans le systeme d6crit, 
conform6raent ^ 1' invention, est particulierement utile car 
il permet de gen§rer automat iquement des patrons k partir 
de MIBs ou de PIBs pour tout type de structure de donn6es 
en dechargeant I'etre humain de ttches fastidieuses qui en 
absence de 1' invention, auraient consiste k definir 
manuellement un patron pour chaque structure de donnees 
particuliere, la quantite de structures de donnees 
possibles dans ce domaine 6tant considerable. 
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Annexe 1 

bufferControlTable OBJECT-TYPE 
SYNTAX SEQUENCE OF { 



bufferControl Index 


Integer32, 


bufferControlChannellndex 


Integer32, 


bufferControlFullStatus 


INTEGER. 


bufferControlFullAction 


INTEGER, 


bufferControlCaptureSliceSize 


Integer32, 


bufferControlDownloadSliceSize 


Integer32, 


bufferControlDownloadOffset 


Integer32, 


bufferControlMaxOctetsRequested 


Integer32, 


bufferControlMaxOctetsGranted 


Integer32, 


bufferControlCapturedPackets 


lnteger32, 


bufferControlTurnOnTime 


TimeTicks, 


bufferControlOwner 


OwnerString, 


bufferControlStatus 


EntryStatus 



} 

INDEX { bufferControllndex } 
20 ::= { capture 1 } 
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Annexe 2 
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aalSVccTable OBJECT-TYPE 

SYNTAX SEQUENCE OF { . 

aalSVccVpi INTEGER, 
aalSVccVci INTEGER, 
aalSVccCrcErrors Counter32, 
aalSVccSarTimeOuts Counter32, 
aalSVccOverSlzedSDUs Counter32 

} 

INDEX { iflndex. aalSVccVpi, aalSVccVcl } 
::= { atmMIBObjects 1 } 



f 
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Revendications : 

1. Procede pour minimiser une bande passante necessaire 
aux transferts d ' informations d' administration de reseau 

5 de communication, lesdites informations concernant des 
objets relatifs a des elements materiels, logiciels ou de 
fonctionnement de reseau, repertories dans une base 
d* information d' administration (11) et a chacun desquels 
est associee une specification en langage formel, 
10 caract^ris^ en ce qu'il comprend des etapes consistant k: 

- generer (48-50) ^ partir de ladite specification pour 
chaque objet, un couple de mots (121) dont la valeur du 
premier mot est relative S une indication de I'objet et la 
valeur du deuxieme mot est relative a une longueur 

15 d' information de I'objet; 

construire (41-47,51-61) un patron comprenant un 
ensemble ordonne de couples de mots (121-133) generes et 
un identif icateur (119-120) dudit patron, permettant 
d^emettre ensuite une suite ordonnee (99-113) 

20 d' informations correspondant audit patron. 

2. Procede selon la revendication 1, caract6rise en ce 
qu'il comprend des §tapes consistant k: 

- parcourir (43-46) un arbre de la base d ' information 
25 d' administration (11) dont chaque noeud est associe a un 

.-.bjot; 
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- construire (51-61) un autre patron dit de table si 
I'objet est de type table pour les objets de la table. 

3, Precede selon la revendication 1 ou 2, caract6ris6 en 
ce qu'il comprend des Stapes consistant ci construire (33- 
37,19-22) en plus un patrdn de configuration comprenant 
les couples de mots g6ner6's pour des objets a acc^s 
modifiable. 

4. Systdime pour minimiser une bande passante necessaire 
aux transferts d' informations d' administration de reseau 
de communication, lesdites informations concernant des 
objets relatifs a des. elements . mater iels, logiciels ou de 
fonctionnement de reseau, repertories dans une, base 
d' information d! administration (11) ' et a chacun desquels 
est associ6e une specification en langage formel:. 
caract6ris6 en ce qu'il comprend un module traducteur (10) 
agenci pour g6h6rer a partir de ladite specification popr 
chaque objet, un couple de mots dont la valeur du premier 
mot est relative a une indication, de I'objet et la valeur 
du deuxi^me mot est relative It une longueur d' information 
de I'objet et pour generer un patron comprenant un 
ensemble ordonne de couples de mots et un identif icateur, 
permettant d'emettre ensuite une suite. ordonnee 
d' informations correspondant audit patron. 

5. systeme selori la. revendication 4 caracterise en ce 
que le module traducteur (10) est agenc^ pour parcourir un 
arbre de la base d' information d' administration (11) dont 
chaque noeud est associe a un objet, pour ^tester ^ chaque 
noeud si I'objet est de type scalaire ou table et pour 
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construire le patron en ajoutant le couple de mots gen6r§ 
au patron si I'objet est de type scalaire ou construire un 
autre patron dit de table si I'objet est de type table 
pour les objets de la table. 

5 

6. Systeme selon la revendication 4 ou 5, caracterise en 
ce que le module traducteur (10) est agence pour 
construire en plus un patron de configuration comprenant 
les couples de mots g6ner6s pour des objets a acces 

10 modifiable. 

7. Systeme selon I'une des revendications 4 a 6, 
caract6ris6 en ce qu'il comprend un module superviseur 
(87) agence pour collecter des mesures et un module 

15 d' exportation (88) agence pour transmettre k un serveur 
(92), au moins un ticket de donn^es relatives a ces 
mesures en le faisant preceder du patron de ce ticket de 
donnees • 
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Fig.3a 

Lire demande de g6n6ration de patrons 
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n\nneroDuChampCoiiraiit_Defricket_ObjetRoot :== 0 
current J:emplate_ID := base_template_ID 
ObjetRootJ;emplate__ID := current_template_ID 
current_template_ID := current_template_ID + 1 




DefTicket_configxiration_Obj etRoot_Template_ID 
:= current_template_ID 
nombreDeChamps_Configuration_ObjetRoot 
:=0 



1 

ciirrent^template^ID 


:= current template_ID + 1 







Parcours 
arbre 




( 
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Parcours table 
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Definition SMI de Tobjet 
^ typedeTobjet 
sous type de I'objet 
taille minimale de Tobjet 
^ taille xnaximalede I'objet 
moded'acces 



OID objet 
tj^e de Tobjet 
sous type de Tobjet 
tmlle minimale de Tobjet 
taille maximale de I'objet 
num^roDuChampCourant 
rfegle de traduction 

module de typage 



8^ 



Module de typage 
(type,longueur) 



50^ 



(type,longueiir) -> 
DefTicket X 




OUl. 
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NombreDeClaamps_ 
Configm;ation 



(type.longueur) -> 
DefTiclcet_Configuration_X 



retour 
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cl6ture ) ^^^-^ 63 

nil ^ 













(type,longueur) -> 
debut de DefTicket^X 


► 


Template_X_ID -> type 
nxmieroDuChamp_X -> longueur 


















DefinitionDeTemplateDeMIB -> type 
4 * (numeroDuChamp_X + 2) -> longueur 


— ► 


(type,longueur) -> 
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